最近发现后台服务器报错：

文件打开数过多最坏的情况可以使系统崩溃，到时候只能是重起服务器了。

打开的文件过多，一般来说是由于应用程序对资源使用不当造成，比如没有及时关闭Socket或数据库连接等。但也可能应用确实需要打开比较多的文件句柄，而系统本身的设置限制了这一数量。

解决思路:

1.尽量把类打成jar包,因为一个jar包只消耗一个文件句柄,如果不打包,一个类就消耗一个文件句柄.2.java的垃圾回收不能关闭网络连接打开的文件句柄,如果没有执行close()(例如:java.net.Socket.close())则文件句柄将一直存在,而不能被关闭.你也可以考虑设置socket的最大打开数来控制这个问题.3.对操作系统做相关的设置,增加最大文件句柄数量。

思考自己的系统：

这个问题连续出现三次，得亏是测试环境。回头搂代码发现，有一个定时刷新配置的任务，每次都会打开一个文件，用完后流没有关闭。又看了下系统的相关配置：

tomcat配置：发现最多能够打开1000个文件

系统配置：发现也是1000，命令：ulimit -a

查看tomcat打开文件的数量：

1、ps -ef |grep tomcat目录，得到PID

2、lsof -p 1305 | wc -l，得到已经打开的数量

发现已经打开的数量未1261个，超过了1000，导致服务停了

服务器端修改：

查看系统允许打开的最大文件数

#cat /proc/sys/fs/file-max

查看每个用户允许打开的最大文件数ulimit -a 发现系统默认的是open files (-n) 1024，问题就出现在这里。

在系统文件/etc/security/limits.conf中修改这个数量限制，在文件中加入内容：

另外方法： 1.使用ps -ef |grep java (java代表你程序，查看你程序进程) 查看你的进程ID，记录ID号，假设进程ID为1305 2.使用：lsof -p 1305 | wc -l 查看当前进程id为1305的 文件操作状况 执行该命令出现文件使用情况为 1192 3.使用命令：ulimit -a 查看每个用户允许打开的最大文件数 发现系统默认的是open files (-n) 1024，问题就出现在这里。 4.然后执行：ulimit -n 4096 将open files (-n) 1024 设置成open files (-n) 4096

这样就增大了用户允许打开的最大文件数